home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / protocol / standard / ccitt / 1992 / x / x509_2.asc < prev    next >
Text File  |  1993-07-14  |  45KB  |  1,137 lines
  1.          The drawings contained in this Recommendation have been done in AUTOCAD
  2.                                                    ANNEX A
  3.                                      (to Recommendation X.509)
  4.                                        Security requirements
  5.                This Annex does not form an integral part of this Recommendation.
  6.                [Additional material relevant to this topic can be  found  in  OSI  7498  -
  7.          Information  Processing  Systems  -  OSI  Reference  Model  -  Part  2,  Security
  8.          Architecture.]
  9.                Many  OSI  applications,  CCITT-defined  services   and   non-CCITT-defined
  10.          services will have requirements for security. Such requirements derive  from  the
  11.          need to protect the transfer of information from a range of potential threats.
  12.          A.1    Threats
  13.                Some commonly known threats are:
  14.                a)  identity interception: the identity  of  one  or  more  of  the  users
  15.                   involved in a communication is observed for misuse;
  16.                b)  masquerade: the pretense by a user to be a different user in order  to
  17.                   gain access to information or to acquire additional privileges;
  18.                c)  replay: the recording and subsequent replay of a communication at some
  19.                   later date;
  20.                d)  data interception: the observation of user data during a communication
  21.                   by an unauthorized user;
  22.                e)  manipulation: the replacement, insertion, deletion or  misordering  of
  23.                   user data during a communication by an unauthorized user;
  24.                f)  repudiation: the denial by a user of having participated in part or all 
  25.                   of a communication;
  26.                g)  denial of service: the prevention or interruption of a communication or 
  27.                   the delay of time-critical operations;
  28.                   Note - This security threat is a more general one and  depends  on  the
  29.                   individual  application  or  on  the  intention  of  the   unauthorized
  30.                   disruption and is therefore not explicitly  within  the  scope  of  the
  31.                   authentication framework.
  32.                h)  mis-routing: the mis-routing of a communication path intended for  one
  33.                   user to another;
  34.                   Note - Mis-routing will naturally occur in OSI layers 1 - 3.  Therefore
  35.                   mis-routing is outside of the scope of  the  authentication  framework.
  36.                   However, it may be possible to avoid the consequences of mis-routing by
  37.                   using  appropriate   security   services   as   provided   within   the
  38.                   authentication framework.
  39.                i)  traffic analysis: the observation of information about a communication
  40.                   between users (e.g. absence/presence, frequency,  direction,  sequence,
  41.                   type, amount, etc.).
  42.                   Note - Traffic analysis threats  are  naturally  not  restricted  to  a
  43.                   certain OSI layer.  Therefore traffic analysis is generally outside the
  44.                   scope of the authentication framework. However, traffic analysis can be
  45.                   partially protected against  by  generating  additional  unintelligible
  46.                   traffic (traffic padding), using enciphered or random data.
  47.          A.2    Security services
  48.                In order to protect against perceived threats,  various  security  services
  49.          need to be  provided.   Security  services  as  provided  by  the  authentication
  50.          framework are performed by means of the security mechanisms described in  A.3  of
  51.          this Annex.
  52.                a)  peer entity authentication: this service provides corroboration that a
  53.                   user in a certain instance of communication is  the  one  claimed.  Two
  54.                   different peer entity authentication services may be requested:
  55.                   -    single  entity   authentication   (either   data   origin   entity
  56.                       authentication or data recipient entity authentication);
  57.                   -   mutual authentication, where both users communicating  authenticate
  58.                       each other.
  59.                   When requesting a peer entity authentication  service,  the  two  users
  60.                   agree whether their identities will be protected or not.
  61.                   The  peer  entity  authentication   service   is   supported   by   the
  62.                   authentication framework.  It can be used to protect against masquerade
  63.                   and replay, concerning the user's identities;
  64.                b)  access control: this service  can  be  used  to  protect  against  the
  65.                   unauthorized use of resources. The access control service  is  provided
  66.  
  67.  
  68.  
  69.  
  70.                                                       Fascicle VIII.8 - Rec. X.511  PAGE21
  71.  
  72.                by the Directory or another application and is therefore not a  concern
  73.                   of the authentication framework;
  74.                c)  data  confidentiality:  this  service  can  be  used  to  provide  for
  75.                   protection   of   data   from   unauthorized   disclosure.   The   data
  76.                   confidentiality service is supported by the  authentication  framework.
  77.                   It can be used to protect against data interception;
  78.                d)  data integrity: this service provides proof of the integrity of data in 
  79.                   a communication.  The  data  integrity  service  is  supported  by  the
  80.                   authentication framework. It can be used to detect and protect  against
  81.                   manipulation;
  82.                e)  non-repudiation: this service provides  proof  of  the  integrity  and
  83.                   origin of data - both in an unforgeable relationship  -  which  can  be
  84.                   verified by any third party at any time.
  85.          A.3    Security mechanisms
  86.                The  security  mechanisms  outlined  here  perform  the  security  services
  87.          described in A.2.
  88.                a)  autbhentication exchange:  there  are  two  grades  of  authentication
  89.                   framework:
  90.                   -   simple authentication: relies on the originator supplying its  name
  91.                       and password, which are checked by the recipient;
  92.                   -    strong  authentication:  relies  on  the  use   of   cryptographic
  93.                       techniques to protect the exchange of  validating  information.  In
  94.                       the authentication framework, strong authentication is  based  upon
  95.                       an asymmetric scheme.
  96.                   The authentication exchange mechanism  is  used  to  support  the  peer
  97.                       entity authentication service;
  98.                b)  encipherment: the authentication framework envisages the  encipherment
  99.                   of data during transfer. Either asymmetric or symmetric schemes may  be
  100.                   used. The necessary key exchange for either case  is  performed  either
  101.                   within a preceding authentication exchange or off-line any time  before
  102.                   the intended communication. The latter case is outside the scope of the
  103.                   authentication framework. The encipherment mechanism supports the  data
  104.                   confidentiality service;
  105.                c)   data  integrity:  this  mechanism  involves  the  encipherment  of  a
  106.                   compressed string of the relevant data to be transferred. Together with
  107.                   the plain data, this message is sent to the  recipient.  The  recipient
  108.                   repeats the compressing and subsequent encipherment of the  plain  data
  109.                   and compares the results with that created by the originator  to  prove
  110.                   integrity.
  111.                   The data integrity mechanism can be provided  by  encipherment  of  the
  112.                   compressed plain data by either an asymmetric  scheme  or  a  symmetric
  113.                   scheme. (With the symmetric scheme,  compression  and  encipherment  of
  114.                   data  might  be  processed  simultaneously.)  The  mechanism   is   not
  115.                   explicitely provided by the authentication  framework.  However  it  is
  116.                   fully provided as a part of the digital signature mechanism (see below)
  117.                   using an asymmetric scheme.
  118.                   The data integrity mechanism supports the data  integrity  service.  It
  119.                   also partially supports the non-repudiation service (that service  also
  120.                   needs the digital signature mechanism for its requirement to  be  fully
  121.                   met);
  122.                d)  digital signature: this mechanism involves the  encipherment,  by  the
  123.                   originator's secret key, of a compressed string of the relevant data to
  124.                   be transferred.  The digital signature together with the plain data  is
  125.                   sent to the recipient. Similarly to the  case  of  the  data  integrity
  126.                   mechanism,  this  message  is  processed  by  the  recipient  to  prove
  127.                   integrity. The digital signature mechanism also proves the authenticity
  128.                   of  the  originator  and  the  unambiguous  relationship  between   the
  129.                   originator and the data that was transferred.
  130.                   The authentication framework supports the digital  signature  mechanism
  131.                   using an asymmetric scheme.
  132.                   The digital signature mechanism supports the data integrity service and
  133.                   also supports the non-repudiation service.
  134.          A.4    Threats protected against by the security services
  135.                The table at the end of this Annex indicates  the  security  threats  which
  136.          each security service can protect  against.  The  presence  of  an  asterisk  (*)
  137.  
  138.  
  139.  
  140.  
  141.          PAGE21  Fascicle VIII.8 - Rec. X.511
  142.  
  143.           indicates that a certain security service affords protection  against  a  certain
  144.           threat.
  145.           A.5    Negotiation of security services and mechanisms
  146.                 The provision of security features  during  an  instance  of  communication
  147.           requires the negotiation of the context in which security services are  required.
  148.           This entails agreement on the type of security mechanisms and security parameters
  149.           that are necessary to provide such security services. The procedures required for
  150.           negotiating mechanisms and parameters can either be carried out  as  an  integral
  151.           part of the normal connection establishment procedure or as a  separate  process.
  152.           The precise details of these procedures for negotiation are not specified in this
  153.           Annex.
  154.  
  155.                                                SERVICES
  156.           THREATS                     Entity             Data         Data         Non-
  157.                                   Authentication    Confidentiali  Integrit   Repudiation
  158.                                                           ty            y      
  159.           Identity             * (if                                           
  160.           Interception         req'd)               
  161.           Data interception                         *                          
  162.           Masquerade           *                                               
  163.           Replay               *                                    * (data)   *
  164.                                (identity)           
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.                                                        Fascicle VIII.8 - Rec. X.511  PAGE21
  213.  
  214.          Manipulation                                                 *       *
  215.          Repudiation                                                          *
  216.                                                    ANNEX B
  217.                                      (to Recommendation X.509)
  218.                              An introduction to public key cryptography
  219.                This Annex does not form an integral part of this Recommendation.
  220.                In  conventional  cryptographic  systems,  the   key   used   to   encipher
  221.          information by the originator of a secret message is the same  as  that  used  to
  222.          decipher the message by the legitimate recipient.
  223.                In public key cryptosystems (PKCS), however, keys come in  pairs,  one  key
  224.          of which is used for enciphering and the other for deciphering. Each key pair  is
  225.          associated with a particular user X. One of the keys, known  as  the  public  key
  226.          (Xp) is publicly known, and can be used by any user to encipher data. Only X, who
  227.          possesses the complementary secret key (Xs)  may  decipher  the  data.  (This  is
  228.          represented notationally by D = Xs[Xp[D]].) It is computationally  infeasible  to
  229.          derive the secret key from knowledge  of  the  public  key.  Any  user  can  thus
  230.          communicate a piece of information which only X can find out, by  enciphering  it
  231.          under Xp. By extension, two users  can  communicate  in  secret,  by  using  each
  232.          other's public key to encipher the data, as shown in Figure B-1/X.509.
  233.                                        FIGURE B-1/X.509 - T0704470-88
  234.  
  235.                User A has public key Ap and secret key As, and user B has another  set  of
  236.          keys, Bp and Bs. A and B both know the public keys of each other, but are unaware
  237.          of the secret key of the other party. A  and  B  may  therefore  exchange  secret
  238.          information with one another using the following steps (illustrated in Figu e  B-
  239.          1/X.509):
  240.                1)  A wishes to send some secret information x to B. A therefore enciphers
  241.                   x under B's enciphering key and sends the enciphered information  e  to
  242.                   B. This is represented by:
  243.                   e = Bp[x].
  244.                2)  B may now decipher this encipherment e to obtain the information x  by
  245.                   using the secret decipherment key Bs. Note that B is the only possessor
  246.                   of Bs, and because this key may never  be  disclosed  or  sent,  it  is
  247.                   impossible for any  other  party  to  obtain  the  information  x.  The
  248.                   possession of  Bs  determines  the  identity  of  B.  The  decipherment
  249.                   operation is represented by:
  250.                   x = Bs[e], or x = Bs[Bp[x]].
  251.                3)  B may now similarly send some secret information, xw', to A, under A's
  252.                   enciphering key, Ap:
  253.                   ew' = Ap[xw'].  
  254.                4)  A obtains xw' by deciphering ew':
  255.                   xw' = As[ew'], or xw' = As[Ap[xw']].
  256.                By this means, A and B have exchanged secret information x  and  xw'.  This
  257.          information may not be obtained by anyone other than  A  and  B,  providing  that
  258.          their secret keys are not revealed.
  259.                Such an exchange can, as well as transferring  secret  information  between
  260.          the parties, serve  to  verify  their  identities.  Specifically,  A  and  B  are
  261.          identified by their  possession  of  the  secret  deciphering  keys,  As  and  Bs
  262.          respectively. A may determine if B is in possession  of  the  secret  deciphering
  263.          key, Bs, by having returned part of his information x in B's  message  xw'.  This
  264.          indicates to A that communication is taking place with the possessor of Bs. B may
  265.          similarly test the identity of A.
  266.                It is  a  property  of  some  PKCS  that  the  steps  of  decipherment  and
  267.          encipherment can be reversed, as in  D  =  Xp[Xs[D]].  This  allows  a  piece  of
  268.          information which could only have been originated by X, to  be  readable  by  any
  269.          user (who has possession of Xp). This can therefore be used in the certifying  of
  270.          the source of information, and is the basis for  digital  signatures.  Only  PKCS
  271.          which  have  this  (permutability)  property  are  suitable  for  use   in   this
  272.          authentication framework. One such algorithm is described in Annex C.
  273.                For further information, see:
  274.          DIFFIE, W. and HELLMAN, M. E. (November 1976) - New Directions  in  Cryptography,
  275.          IEEE Transactions on Information Theory, IT-22, No. 6.
  276.                                                    ANNEX C
  277.                                      (to Recommendation X.509)
  278.                                   The RSA public key cryptosystem
  279.  
  280.  
  281.  
  282.  
  283.          PAGE21  Fascicle VIII.8 - Rec. X.511
  284.  
  285.                This Annex does not form an integral part of this Recommendation.
  286.          Note  -  The  cryptosystem  specified  in  this  Annex,  which  was  invented  by
  287.          R. L. Rivest, A. Shamir and L. Adleman, is widely known as "RSA".
  288.          C.1    Scope and field of application
  289.                It is beyond the scope of this paper  to  discuss  RSA  fully.  However,  a
  290.          brief description is given on the method, which relies  on  the  use  of  modular
  291.          exponentiation.
  292.          C.2    References
  293.                For further information, see:
  294.                1)  General
  295.                   RIVEST, R. L., SHAMIR, A. and ADLEMAN, L. (February 1978)  -  A  Method
  296.                   for  Obtaining  Digital  Signatures   and   Public-key   Cryptosystems,
  297.                   Communications of the ACM, 21, 2,     120-126.
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.                                                       Fascicle VIII.8 - Rec. X.511  PAGE21
  355.  
  356.                2)  Key Generation Reference
  357.                   GORDON, J. - Strong RSA Keys, Electronics Letters, 20, 5, 514-516.
  358.                3)  Decipherment Reference
  359.                   QUISQUATER,  J.  J.  and  COUVREUR,  C.  (October  14,  1982)  -   Fast
  360.                   Decipherment Algorithm for RSA  Public-key  Cryptosystems,  Electronics
  361.                   Letters, 18, 21, 905-907.
  362.          C.3    Definitions
  363.                a)  public key: the pair of parameters consisting of the  Public  Exponent
  364.                   and the Arithmetic Modulus;
  365.                   Note - The ASN.1 data element subjectPublicKey defined  as  BIT  STRING
  366.                   (see Annex G), should be interpreted in the case of  RSA  as  being  of
  367.                   type:
  368.                   SEQUENCE  {INTEGER,INTEGER}
  369.                   where the first integer is the Arithmetic Modulus and the second is the
  370.                   Public Exponent.  The sequence is represented by  means  of  the  ASN.1
  371.                   Basic Encoding Rules.
  372.                b)  secret key: the pair of parameters consisting of the  Secret  Exponent
  373.                   and the Arithmetic Modulus.
  374.          C.4    Symbols and abbreviations
  375.                X,Ydata blocks which are arithmetically less than the modulus
  376.                n   the Arithmetic Modulus
  377.                e   the Public Exponent
  378.                d   the Secret Exponent
  379.                p,qthe prime numbers whose product forms the Arithmetic Modulus (n).
  380.                Note - While the prime numbers are preferably two in number, the use  of  a
  381.          Modulus with three- or more prime factors is not precluded.
  382.                mod n arithmetic modulo n.
  383.          C.5    Description
  384.                This asymmetric algorithm uses the power  function  for  transformation  of
  385.          data blocks such that:
  386.                Y = Xemod n  with 0 < X < n
  387.                X = Ydmod n       0 < Y < n
  388.          which may be satisfied, for example, by
  389.                ed mod lcm(p-1,q-1=1,
  390.                ed mod (p-1)(q-1)=1
  391.                To effect this process, a data block must be  interpreted  as  an  integer.
  392.          This is accomplished by considering the  entire  data  block  to  be  an  ordered
  393.          sequence of bits (of length l, say). The integer is then formed as the sum of the
  394.          bits after giving a weight of 2l-1 to the first bit and dividing the weight by  2
  395.          for each subsequent bit (the last bit has a weight of 1).
  396.                The data block length should be the largest  number  of  octets  containing
  397.          fewer bits than the modulus. Incomplete  blocks  should  be  padded  in  any  way
  398.          desired. Any number of blocks of additional padding may be added.
  399.          C.6    Security requirements
  400.          C.6.1  Key lengths
  401.                It is recognized that the acceptable key length is likely  to  change  with
  402.          time, subject to the cost and availability of hardware, the time taken,  advances
  403.          in techniques and the level of security required. It is recommended that a  value
  404.          for the length of n of 512 bits be adopted  initially,  but  subject  to  further
  405.          study.
  406.          C.6.2  Key generation
  407.                The security of RSA relies on the difficulty of factorizing  n.  There  are
  408.          many algorithms for performing this operation, and in order to thwart the use  of
  409.          any currently known technique, the values p  and  q  must  be  chosen  carefully,
  410.          according to the following rules [e.g. see Reference 2), Section C.2]:
  411.                a)  they should be chosen randomly;
  412.                b)  they should be large;
  413.                c)  they should be prime;
  414.                d)  |p-q| should be large;
  415.                e)  (p+1) must possess a large prime factor;
  416.                f)  (q+1) must possess a large prime factor;
  417.                g)  (p-1) must possess a large prime factor, say r;
  418.                h)  (q-1) must possess a large prime factor, say s;
  419.                i)  (r-1) must possess a large prime factor;
  420.                j)  (s-1) must possess a large prime factor.
  421.  
  422.  
  423.  
  424.  
  425.          PAGE21  Fascicle VIII.8 - Rec. X.511
  426.  
  427.                 After generating the public and secret keys, e.g. "Xp" and "Xs" as  defined
  428.           in  3.3 and  4.1 of this Recommendation which consist of d, e and n, the values p
  429.           and q together with all other data produced such as the product (p-1)  (q-1)  and
  430.           the large prime factors should preferably be destroyed. However, keeping p and  q
  431.           locally can improve throughput in decryption by two to four times.  The  decision
  432.           to keep p and q is considered to be a local matter [Reference 3)].
  433.                 It must be ensured that e > log2(n) in order to prevent  attack  by  taking
  434.           the e'th root mod n to disclose the plaintext.
  435.           C.7    Public exponent
  436.                 The Public Exponent (e) could be common to the whole environment, in  order
  437.           to minimize the length of that part of the public key that  actually  has  to  be
  438.           distributed,  in  order  to  reduce  transmission  capacity  and  complexity   of
  439.           transformation (see Note 1).
  440.                 Exponent e should be large enough  but  such  that  exponentiation  can  be
  441.           performed efficiently with regard to processing time and storage capacity.  If  a
  442.           fixed public exponent e is desired, there are notable merits for the use  of  the
  443.           Fermat Number F4 (see Note 2).
  444.                 eq F4 = 22\s\up6(4) + 1
  445.                 = 65537 decimal, and
  446.                 = 1 0000 0000 0000 0001 binary.
  447.                 Note 1 - Although both Modulus n and Exponent e  are  public,  the  Modulus
  448.           should not be the part which is common to a group of users. Knowledge of  Modulus
  449.           "n", Public Exponent "e" and Secret Exponent "d" is sufficient to  determine  the
  450.           factorization of "n". Therefore if the modulus was common, everyone could  deduce
  451.           its factors, thereby finding everyone else's secret exponent.
  452.                 Note 2 - The fixed exponent should be large and prime but  it  should  also
  453.           provide efficient processing. Fermat Number F4  meets  these  requirements,  e.g.
  454.           authentication takes only 17 multiplications and  is  on  the  average  30  times
  455.           faster than decipherment.
  456.           C.8    Conformance
  457.                 Whilst this  Annex  specifies  an  algorithm  for  the  public  and  secret
  458.           functions, it does not define the method whereby  the  calculations  are  carried
  459.           out; therefore there may be different products which comply with this  Annex  and
  460.           are mutually compatible.
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.                                                        Fascicle VIII.8 - Rec. X.511  PAGE21
  497.  
  498.                                                    ANNEX D
  499.                                      (to Recommendation X.509)
  500.                                            Hash functions
  501.                This Annex does not form an integral part of this Recommendation.
  502.          D.1    Requirements for hash functions
  503.                To use a hash function as  a  secure  one-way  function,  it  must  not  be
  504.          possible to obtain easily the same hash result from different combinations of the
  505.          input message.
  506.                A strong hash function will meet the following requirements:
  507.                a)  the hash function must be one-way, i.e. given any possible hash result
  508.                   it must be computationally infeasible to  construct  an  input  message
  509.                   which hashes to this result;
  510.                b)   the  hash  function  must  be  collision-free,  i.e.   it   must   be
  511.                   computationally infeasible to construct  two  distinct  input  messages
  512.                   which hash to the same result.
  513.          D.2    Description of a hash function
  514.                The following hash function ("square-mod n") performs  the  compression  of
  515.          the data on a block by block basis.
  516.                Hashing is done in three major steps:
  517.                1)  The string of data to be hashed is divided  into  blocks  B  of  equal
  518.                   length. This  length  is  determined  by  the  characteristics  of  the
  519.                   asymmetric cryptosystem used for signing. With  the  RSA  cryptosystem,
  520.                   this length (in octets) is the largest  integer,  l,  such  that,  with
  521.                   modulus n, 16 l < log2 n.
  522.                2)  For non-invertibility reasons each octet of the block is split in half. 
  523.                   Each of the halves is headed ("padded") by binary ones. By this zoning,
  524.                   stiffness  r  redundancy  is  introduced  that   increases   the   non-
  525.                   invertibility property of the hash function  considerably.  Each  block
  526.                   generated in step 1 is spread to the length of the modulus n.
  527.                3)  Each block resulting from step 2 is added to the previous block modulo
  528.                   2, squared, and reduced modulo n, until all m blocks are processed.
  529.                   The result is thus the value Hm, where
  530.                   H0 = 0
  531.                   Hi = (Hi-1 + Bi)2 mod n, for 1 < i < m
  532.                If the last block of the data to be hashed  is  incomplete,  it  is  padded
  533.          with "l"s.
  534.                                                    ANNEX E
  535.                                      (to Recommendation X.509)
  536.                    Threats protected against by the strong authentication method
  537.                This Annex does not form an integral part of this Recommendation.
  538.                The strong authentication method described in  this  Recommendation  offers
  539.          protection against the threats as described in Annex A for strong authentication.
  540.                In addition, there is a range of potential threats  that  are  specific  to
  541.          the strong authentication method itself. These are:
  542.                Compromise of the user's secret key  -  one  of  the  basic  principles  of
  543.          strong authentication is that the user's secret key remain secure.  A  number  of
  544.          practical methods are available for the user to hold his secret key in  a  manner
  545.          that provides adequate security. The consequences of the compromise  are  limited
  546.          to subversion of communication involving that user.
  547.                Compromise of the CA's secret key - that the secret  key  of  a  CA  remain
  548.          secure is also a basic principle of strong authentication. Physical security  and
  549.          "need to know" methods apply. The consequences of the compromise are  limited  to
  550.          subversion of communication involving any user certified by that CA.
  551.                Misleading CA into producing an invalid certificate -  the  fact  that  CAs
  552.          are off-line affords some protection. The  onus  is  on  the  CA  to  check  that
  553.          purported strong  credentials  are  valid  before  creating  a  certificate.  The
  554.          consequences of  the  compromise  are  limited  to  subversion  of  communication
  555.          involving the user for whom the certificate was created, and anyone  impacted  by
  556.          the invalid certificate.
  557.                Collusion between a rogue CA and  user  -  such  a  collusive  attack  will
  558.          defeat the method. This would constitute a betrayal of the trust  placed  in  the
  559.          CA. The consequences of a rogue CA are limited  to  subversion  of  communication
  560.          involving any user certified by that CA.
  561.                Forging of a  certificate  -  the  strong  authentication  method  protects
  562.          against the forging of a certificate by having the CA sign it. The method depends
  563.  
  564.  
  565.  
  566.  
  567.          PAGE21  Fascicle VIII.8 - Rec. X.511
  568.  
  569.           on maintaining the secrecy of the CA's secret key.
  570.                 Forging of a token - the strong authentication method protects against  the
  571.           forging of a  token  by  having  the  sender  sign  it.  The  method  depends  on
  572.           maintaining the secrecy of the sender's secret key.
  573.                 Replay of a token - the one- and  two-way  authentication  methods  protect
  574.           against the replay of a token by the inclusion of a timestamp in the  token.  The
  575.           three-way method does so by checking the random numbers.
  576.                 Attack  on  the  cryptographic  system  -  the  likelihood   of   effective
  577.           cryptanalysis of the system, based on advances in computational number theory and
  578.           leading to the need for a greater key length are reasonably predictable.
  579.                                                     ANNEX F
  580.                                       (to Recommendation X.509)
  581.                                          Data confidentiality
  582.                 This Annex does not form an integral part of this Recommendation.
  583.           F.1    Introduction
  584.                 The process of data confidentiality can be initiated  after  the  necessary
  585.           keys for encipherment have been exchanged. This might be provided by a  preceding
  586.           authentication exchange as described in  9 or by some other key exchange process,
  587.           the latter being outside the scope of this document.
  588.                 Data confidentiality can be  provided  either  by  the  application  of  an
  589.           asymmetric or symmetric enciphering scheme.
  590.           F.2    Data confidentiality by asymmetric encipherment
  591.                 In this case Data Confidentiality is performed by means  of  an  originator
  592.           enciphering the data to be sent using the intended recipient's  public  key:  the
  593.           recipient will then decipher it using its secret key.
  594.           F.3    Data confidentiality by symmetric encipherment
  595.                 In this case Data Confidentiality is achieved by the  use  of  a  symmetric
  596.           enciphering algorithm. Its choice is outside  the  scope  of  the  authentication
  597.           framework.
  598.                 Where an authentication exchange according to  9 has been  carried  out  by
  599.           the two parties involved, then a key for the usage of a symmetric  algorithm  can
  600.           be derived. Choosing secret keys depends on the transformation to  be  used.  The
  601.           parties must be sure that they are strong  keys.  This  Recommendation  does  not
  602.           specify how this choice is made, although clearly this would need to be agreed by
  603.           the parties concerned, or specified in other standards.
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.                                                        Fascicle VIII.8 - Rec. X.511  PAGE21
  639.  
  640.                                                    ANNEX G
  641.                                      (to Recommendation X.509)
  642.                                  Authentication framework in ASN.1
  643.                This Annex is part of the Recommendation.
  644.                This Annex includes all of the ASN.1  type,  macro  and  value  definitions
  645.          contained  in  this  Recommendation  in   the   form   of   the   ASN.1   module,
  646.          "AuthenticationFramework".
  647.                AuthenticationFramework {joint-iso-ccitt ds(5) modules(1)
  648.                                    authenticationFramework(7)}
  649.                DEFINITIONS ::=
  650.                BEGIN
  651.                EXPORTS     AlgorithmIdentifier,  AuthorityRevocationList,  CACertificate,
  652.                   Certificate,
  653.                            Certificates,  CertificationPath,   CertificateRevocationList,
  654.                       UserCertificate,
  655.                            CrossCertificatePair, UserPassword, ALGORITHM,
  656.                            ENCRYPTED, PROTECTED, SIGNATURE, SIGNED;
  657.                IMPORTS
  658.                   informationFramework, selectedAttributeTypes, upperBounds
  659.                       FROM UsefulDefinitions {joint-iso-ccitt ds(5)modules(1)
  660.                                  usefulDefinitions(0)}
  661.                   Name, ATTRIBUTE,ATTRIBUTE-SYNTAX
  662.                       FROM InformationFramework informationFramework
  663.                ub-user-passwordFROM Upper Bounds upperBounds;
  664.                -- types
  665.                Certificate    ::=      SIGNED SEQUENCE{
  666.                                  version                 [0] Version DEFAULT 1988,
  667.                                  serialNumber            SerialNumber,
  668.                                  signature         AlgorithmIdentifier,
  669.                                  issuer                  Name,
  670.                                        validity                Validity,
  671.                                  subject                 Name,
  672.                                  subjectPublicKeyInfo    SubjectPublicKeyInfo}
  673.                Version           ::=   INTEGER { 1988(0)}
  674.                SerialNumber            ::=   INTEGER
  675.                Validity          ::=   SEQUENCE{
  676.                                      notBefore           UTCTime
  677.                                      notAfter            UTCTime}
  678.                SubjectPublicKeyInfo    ::= SEQUENCE{
  679.                                        algorithm         AlgorithmIdentifier
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.          PAGE21  Fascicle VIII.8 - Rec. X.511
  710.  
  711.                                        subjectPublicKey        BIT STRING}
  712.                   AlgorithmIdentifier  ::= SEQUENCE{
  713.                                        algorithm         OBJECT IDENTIFIER,
  714.                                        parameters          ANY   DEFINED   BY   algorithm
  715.                       OPTIONAL}
  716.                Certificates      ::=   SEQUENCE{
  717.                                     certificate                Certificate,
  718.                                     certificationPath            ForwardCertificationPath
  719.                          OPTIONAL}
  720.                ForwardCertificationPath      ::=   SEQUENCE OF CrossCertificates
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.                                                       Fascicle VIII.8 - Rec. X.511  PAGE21
  781.  
  782.                CertificationPath ::=    SEQUENCE{
  783.                                        userCertificate         Certificate,
  784.                                        theCACertificates SEQUENCE OF CertificatePair
  785.                                                                      OPTIONAL}
  786.                   CrossCertificates    ::= SET OF Certificate
  787.                   CertificateList      ::= SIGNED SEQUENCE{
  788.                                        signature         AlgorithmIdentifier,
  789.                                        issuer                  Name,
  790.                                        lastUpdate        UTCTime,
  791.                                        revokedCertificates 
  792.                             SIGNEDSEQUENCE OF SEQUENCE{
  793.                                                                signature 
  794.                          AlgorithmIdentifier,
  795.                                                                issuer            Name,
  796.                                                                userCertificate 
  797.                          SerialNumber,
  798.                                                                revocationDate    UTCTime}
  799.                                                                         OPTIONAL}
  800.                CertificatePair   ::= SEQUENCE{
  801.                                  forward [0]       Certificate OPTIONAL,
  802.                                  reverse [1]       Certificate OPTIONAL
  803.                                  - -at least one of the pair must be present --}
  804.                --attribute types
  805.                UserCertificate               ::=   ATTRIBUTE
  806.                                              WITH ATTRIBUTE-SYNTAXCertificate
  807.                CACertificate                 ::=   ATTRIBUTE
  808.                                              WITH ATTRIBUTE-SYNTAXCertificate
  809.                CrossCertificatePair          ::=   ATTRIBUTE
  810.                                                    WITH ATTRIBUTE-SYNTAXCertificatePair
  811.                CertificateRevocationList     ::=   ATTRIBUTE
  812.                                                    WITH ATTRIBUTE-SYNTAXCertificateList
  813.                AuthorityRevocationList ::=   ATTRIBUTE
  814.                                                    WITH ATTRIBUTE-SYNTAXCertificateList
  815.                   UserPassword         ::=   ATTRIBUTE
  816.                                                    WITH ATTRIBUTE-SYNTAX
  817.                                                    OCTETSTRING(SIZE(0...ub-user-password))
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.          PAGE21  Fascicle VIII.8 - Rec. X.511
  852.  
  853.                                                    MATCHES FOR EQUALITY
  854.                -- macros
  855.                ALGORITHM MACRO   ::=
  856.                BEGIN
  857.                TYPE NOTATION           ::=   "PARAMETER" type
  858.                VALUE NOTATION          ::=   value(VALUE OBJECT IDENTIFIER)
  859.                END -- of ALGORITHM
  860.                ENCRYPTED MACRO   ::=
  861.                BEGIN
  862.                TYPE NOTATION           ::=   type (ToBeEnciphered)
  863.                VALUENOTATION           ::=   value (VALUE BIT STRING
  864.                   - -the value of the bit string is generated by
  865.                   - -taking the octets which form the complete
  866.                   - -encoding (using the ASN.1 Basic Encoding Rules)
  867.                   - -of the value of the ToBeEnciphered type and
  868.                   - -applying an encipherment procedure to those octets--
  869.                END
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.                                                       Fascicle VIII.8 - Rec. X.511  PAGE21
  923.  
  924.                SIGNED MACRO            ::=
  925.                BEGIN
  926.                TYPE NOTATION           ::=   type (ToBeSigned)
  927.                VALUE NOTATION          ::=   value(VALUE
  928.                SEQUENCE{
  929.                   ToBeSigned,
  930.                   AlgorithmIdentifier, -- of the algorithm used to generate the signature
  931.                   ENCRYPTED OCTET STRING
  932.                   - -where the octet string is the result
  933.                   - -of the hashing of the value of
  934.                   - -"ToBeSigned"- -}
  935.                                    )
  936.                END -- of SIGNED
  937.                SIGNATURE MACRO         ::=
  938.                BEGIN
  939.                TYPE NOTATION           ::=   type (OfSignature)
  940.                VALUE NOTATION          ::=   value(VALUE
  941.                   SEQUENCE{
  942.                       AlgorithmIdentifier,
  943.                       - -of the algorithm used to compute the signature
  944.                       ENCRYPTED OCTET STRING
  945.                       - -where the octet string is  a  function  (e.g.  a  compressed  or
  946.                          hashed version)
  947.                       - -of the value "OfSignature", which may include the identifier  of
  948.                          the
  949.                       --algorithm used to compute the signature- -}
  950.                                                           )
  951.                END -- of SIGNATURE
  952.                PROTECTED MACRO   ::=  SIGNATURE
  953.                END- -of Authentication Framework Definitions
  954.                                                    ANNEX H
  955.                                      (to Recommendation X.509)
  956.                         Reference Definition of algorithm object identifiers
  957.                This Annex is not an integral part of the Recommendation.
  958.                This Annex  defines  object  identifiers  assigned  to  authentication  and
  959.          encryption algorithms, in the absence of a formal register.  It  is  intended  to
  960.          make use of such a register as it becomes available.  The  definitions  take  the
  961.          form of the ASN.1 module, AlgorithmObjectIdentifiers.
  962.                AlgorithmObjectIdentifiers    {joint-iso-ccitt ds(5) modules(1)
  963.                                        algorithmObjectIdentifiers(8)}
  964.                DEFINITIONS ::=
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.          PAGE21  Fascicle VIII.8 - Rec. X.511
  994.  
  995.                BEGIN
  996.                EXPORTS
  997.                   encryptionAlgorithm, hashAlgorithm, signatureAlgorithm,
  998.                   rsa,squareMod-n,sqMod-nWithRSA;
  999.                IMPORTS
  1000.                   algorithm,authenticationFramework
  1001.                       FROM UsefulDefinitions {joint-iso-ccitt ds(5)modules(1)
  1002.                                              usefulDefinitions(0)}
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.  
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.                                                       Fascicle VIII.8 - Rec. X.511  PAGE21
  1065.  
  1066.                       ALGORITHM      FROM AuthenticationFramework authenticationFramework;
  1067.                -- categories of object identifier
  1068.                encryptionAlgorithm OBJECT IDENTIFIER           ::=   {algorithm 1}
  1069.                hashAlgorithm OBJECT IDENTIFIER                 ::=   {algorithm 2}
  1070.                signatureAlgorithm OBJECT IDENTIFIER            ::=   {algorithm 3}
  1071.                -- algorithms
  1072.                rsa    ALGORITHM
  1073.                   PARAMETER KeySize
  1074.                   ::=  {encryptionAlgorithm 1}
  1075.                KeySize ::=  INTEGER
  1076.                sqMod-n ALGORITHM
  1077.                   PARAMETER BlockSize
  1078.                   ::= {hashAlgorithm 1}
  1079.                BlockSize ::=  INTEGER
  1080.                sqMod-nWithRSA ALGORITHM
  1081.                   PARAMETER KeyAndBlockSize
  1082.                   ::= {signatureAlgorithm 1}
  1083.                KeyAndBlockSize ::= INTEGER
  1084.                END -- of Algorithm Object Identifier Definitions
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127.  
  1128.  
  1129.  
  1130.  
  1131.  
  1132.  
  1133.  
  1134.  
  1135.          PAGE21  Fascicle VIII.8 - Rec. X.511
  1136.  
  1137.